fix: upgrade ejs to 3.1.7 (CVE-2022-29078) - #755

Closing — this doesn't actually fix the flagged vulnerability and touches a package we don't use.

Our real EJS template engine is a hand-vendored, browserified bundle at np.Templating/lib/support/ejs.js (embeds version 3.1.6 internally). Nothing in our own code does require('ejs'). The npm ejs@2.6.1 trivy flagged only exists as a deep transitive dep: @codedungeon/gunner → @codedungeon/utils → ejs@2.6.1 (our dev CLI tooling, never shipped to end users).

This PR adds ejs: ^3.1.7 as a brand-new direct dependency, which only bumps the top-level hoisted copy — the actually-flagged nested copy under @codedungeon/utils is left at 2.6.1 because npm can't dedupe across its pinned range. So it's a no-op against the flagged CVE, plus it adds an unused dependency to package.json.

Also, CVE-2022-29078 only matters if outputFunctionName is set from user input when calling ejs.render() — we never set that option anywhere, vendored engine or otherwise, so it isn't reachable through our usage regardless of version.

Fixed properly via an overrides entry in a follow-up PR, which forces every nested copy (including the one this PR missed) to a patched version without adding a fake direct dependency.

Thanks for the detailed breakdown; it makes sense. I appreciate you taking the time to trace it through the dependency tree rather than just closing it outright.

You're right that the automated scan doesn't account for hoisting/dedup behaviour or actual reachability of outputFunctionName, so a top-level version bump was the wrong fix here. Good call using overrides in #759 instead; that's the correct way to force the nested copy without adding a dependency that isn't really used.